Telecommunications services provided over an IP Connectivity Access Network (IP-CAN) can be subject to charging and policy control mechanisms. This includes Quality of Service (QoS) control. Accordingly, some telecommunications systems incorporate so-called Policy and Charging Control (PCC) architectures to provide this control. 3GPP TS 23.203 V8.6.0 (and earlier versions of Release 7) describes such a PCC architecture in respect of packet flows in an IP-CAN session established by a user terminal through an Evolved 3GPP telecommunications system, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. FIG. 1 illustrates schematically an example of the PCC architecture described in 3GPP TS 23.203 that comprises a Policy and Charging Enforcement Function (PCEF), a Bearer Binding and Event Reporting Function (BBERF), a Policy and Charging Rules Function (PCRF), an Application Function (AF), an Online Charging System (OCS), an Offline Charging System (OFCS), and a Subscription Profile Repository (SPR).
The PCRF is a functional element that encompasses policy control decision and flow based charging control functionalities, a combination of the functionality of the Policy Decision Function (PDF) and the Charging Rule Function (CRF) defined in release 6 of the 3GPP specification. A PCRF can be implemented as a standalone node and behaves as a Policy Decision Point (PDP), or Policy Server (PS), that stores user data related to QoS enforcement, access control lists, etc. The PCRF provides policy and charging control for the media components negotiated between the user terminal and the AF. The PCRF receives session and media related information from the AF and informs the AF of traffic plane events. The PCRF also provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF can provision PCC rules and PCC decisions to the PCEF via the Gx reference point. Criteria such as the QoS subscription information may be used together with policy rules such as, service-based, subscription-based, or pre-defined PCRF internal policies to derive the authorized QoS to be enforced for a service data flow. The PCRF PCC decisions may be based on one or more of the following:                information obtained from the AF via the Rx reference point, e.g. the session, media and subscriber related information;        information obtained from the PCEF via the Gx reference point, e.g. IP-CAN bearer attributes, request type, subscriber related information and location information;        information obtained from the SPR via the Sp reference point, e.g. subscriber and service related data;        information pre-defined in the PCRF; and        information obtained from BBERF via the so-called Gxx reference point.        
The PCEF is a functional entity that behaves as a Policy Enforcing Point (PEP) for enforcing decisions instructed by the PCRF and the OCS. The PCEF provides service data flow detection (based on the service data flow filter filters defined in the PCC rules) to capture and analyse any user and signalling traffic, to identify the user and to capture details of the service(s) being used. The PCEF can then communicate this information to the PCRF over the Gx interface, to the OCS over the Gy interface, and to the OFCS over the Gz interface. The PCEF enforces QoS control according to the QoS authorised by the PCRF. The PCEF is typically deployed functionally between an access gateway giving access to a packet data network and an application server giving access to a particular service or set of services. The PCEF is preferably physically co-located within the gateway node implementing the IP access to the PDN. As such, in a GPRS core network the PCEF is located within the GPRS Gateway Support Node (GGSN), whilst in the case of a CDMA2000 network the PCEF may be located in a Packet Data Serving Node (PDSN), and in a WLAN network the PCEF may be located in a Packet Data Gateway (PDG).
The BBERF functionality includes bearer binding, uplink bearer binding verification and event reporting to the PCRF. For example, in a GPRS core network the bearer binding mechanism associates the PCC rule with the PDP context that is to carry the service data flow. When GPRS Tunnelling Protocol (GTP) is used between the BBERF and the PCEF then bearer binding is performed by the PCEF. Alternatively, when Proxy Mobile IP (PMIP) is used between the BBERF and the PCEF, instead of GTP, then bearer binding is performed by the BBERF.
The OCS provides authorization for the usage of network resources based on the provisioned data and the user activity information it receives from PCEF. This authorization is be granted by the OCS prior to the actual resource usage. When receiving a network resource usage request, the network assembles the relevant charging information and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource usage authorization over the Gy interface. The resource usage authorization may be limited in its scope (e.g. volume of data or duration) therefore this authorization may have to be renewed from time to time as long as the user's resource usage persists. The OCS can support time, volume and event-based charging.
The AF is an element offering applications that require policy and/or charging control of the IP-CAN user plane behaviour. The AF communicates with the PCRF over the Rx interface to transfer dynamic session information (e.g. a description of the media to be delivered in the transport layer) required for PCRF decisions, as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events. One example of an AF is the P-CSCF of the IP Multimedia Core Network (IM CN) subsystem. In the case of a P-CSCF, the information communicated over the Rx interface is derived from the P-CSCF session information (e.g. SDP when SIP is used for signalling) and it mainly includes media components. A media component comprises a set of IP flows, each of which is described by a 5-tuple, the media type and required bandwidth.
The SPR contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level PCC rules by the PCRF. The Sp interface allows the PCRF to request subscription information related to the IP-CAN transport level policies from the SPR based on a subscriber ID and other IP-CAN session attributes.
As considered above, one or more of the policies implemented by the PCC architecture may relate to a QoS to be applied to a user and/or session. A basic QoS policy function may comprise, for example, enforcing rules for limiting the bandwidth of a certain communication during a certain period or when a usage quota is exceeded (e.g. measured as a number of data packets sent and/or received). This may be done for the dual purposes of differentiating user service levels to allow for differentiated pricing plans and in order to prevent a small number of users “hogging” large amounts of available access bandwidth to the detriment of other users.
As currently considered, the QoS policy rules applicable to a communication (an “IP-CAN” session according to the terminology of TS 23.203) involving a user terminal depend on the QoS category associated with an identifier received at establishment of the communication. The nature of the identifier (referred to herein as a “connection identifier”) can vary depending on the type of access which the user terminal employs in order to connect to the system. Examples of connection identifier types are a Network Access Identity (NAI) in case of X-DSL access and a Mobile Subscriber Integrated Services Digital Network Number (MSISDN) used to identify a subscription in a GSM or UMTS cellular network. Other connection identifiers include International Mobile Subscriber Identity (IMSI), Mobile Station Identifier (MSID), and Mobile Identification Number (MIN). Connection identifiers are generally registered within the network (e.g. at the SPR) when a subscription is set up for a user. Of course, further identifiers may be added subsequently to a subscription.
Table 1 below illustrates three service plans that an operator may wish to offer to subscribers, namely Voice and Data—“AllnOne”, Only Data—“Premium”, and Only Data—“Professional”. Implementation of such plans requires monitoring data usage associated with a connection identifier, and detecting when that usage has exceeded a subscriber limit. In a PCC architecture, the PCEF can report usage consumed by a connection identifier to the PCRF (e.g. by extending the functionality of the existing Gx interface). The PCRF acts on the reported usage, e.g. by throttling back bandwidth when a subscription limit is reached. Usage limits and accumulated usage may be stored internally in the PCRF or the SPR, e.g. to allow control of a new session associated with a connection identifier to continue where a previous connection finished. In more detail, an example procedure might involve the following steps:                1. The user initiates an IP-CAN session for a given connection identifier (e.g. MSISDN).        2. The PCEF initiates a Gx session requesting applicable PCC rules and QoS values by sending a CCR initial message.        3. The PCRF retrieves the accumulated usage and evaluates the QoS and access policies. It also computes the granted volume/time quota taking into account the usage limits configured for the connection identifier.        4. The PCRF sends the PCC rules, QoS values and granted quota to the PCEF within a CCA message.        5. The User starts to download/upload traffic. The PCEF discounts the usage from the granted volume/time quota for that connection identifier.        6. When the granted quota is exhausted, the PCEF requests a reauthorization to the PCRF by sending a CCR update message, and in the meantime buffers the user data. This message includes the volume and time used from the last usage reporting message.        7. The PCRF accumulates the usage reporting for that connection identifier. It re-evaluates the QoS and access policies. As the usage limit has been exceeded, the evaluation results in a new QoS profile.        8. The PCRF sends the new PCC rules and QoS profile to the PCEF in a CCA message.        9. The PCEF enforces the new QoS profile, allowing user traffic to flow again but with a reduced bandwidth.        
At IP-CAN session termination, the PCRF receives from the PCEF a final usage report, and updates and stores the accumulated usage information. This will be the starting point for the next session.
It will be appreciated that service plans similar to that illustrated in Table 1 may be implemented based upon other types of quota. For example, for VoIP services, a quota may be specified in terms of available talk minutes. A quota may alternatively be specified as a number of times that a particular service may be accessed. All quotas may of course be incorporated into a single service plan.
A problem arises when a given user establishes a second IP-CAN with a second connection identifier whilst a first IP-CAN already exists and is associated with a first, different connection identifier. In this case, according to current implementations, the PCEF associated with the second IP-CAN (which may or may not be the PCEF associated with the first IP-CAN session) will receive from the PCRF, for example, a remaining data volume quota identical to the last quota sent to the PCEF associated with the first IP-CANN. This may result in the user being able to consume significantly more than his or her remaining quota. A similar problem arises when two or more family members, associated with a “family bundle” plan, establish parallel IP-CANs using respective, different, connection identifiers. Current solutions to these problems require different service plans for different connection identifiers. This complicates the offerings that an operator can make to potential subscribers, particularly for those operators owning fixed and mobile networks or deploying new SAE networks where LTE, WiMax and 2G/3G accesses can exist in parallel.